For software debugging or performance analysis, a trace flow enables the reconstruction of a monitored program flow and is therefore useful to determine which kind of events took place before a particular software problem arose. A trace system or architecture is used to observe the behavior of a real time control system (e.g. automotive Electronic Control Unit ECU) on a higher level. Such a real time control system gets input values from sensors from which the control algorithm calculates actuator values. All these values are so called signals, which need to be observed for analyzing the system behavior.
FIG. 1 is a high-level block diagram illustrating a conventional trace architecture for a computer system 10. The conventional trace system is implemented on a microchip and may include one or more central processing units (CPUs) 12 with a trace adapter 12a, one or more busses 14 with a local trace adapter 14a, and a trace unit 16 coupled to receive trace data from the one or more CPUs 12 and the one or more busses 14. The trace unit 16 further comprises a message generator 18 for generating trace data and a message packer 20 for packaging the generated trace data. The message packer 20 then provides the packaged trace data to a multiplexer or replicator 22 which provides the option to output the data to different targets exclusively or in parallel. The packed trace messages are then output either to an on-chip trace buffer 24 or off-chip (not shown) via an off-chip trace interface 26 and pins 28. Typical architectures following this approach are ARM's CoreSight, Infineon's MCDS and Nexus standard compliant architectures.
Conventional trace units such as that shown in FIG. 1 have several disadvantages. Conventional trace units trace the activities of the CPU and bus and utilize the same stream for packed trace messages which are then output to either an on-chip buffer and/or to off-chip interface via pins. One disadvantage of conventional trace units is the limited bandwidth which limits a trace to just the program flow with no or only a few data accesses, e.g. qualified by an address range. For finding sporadic bugs in a hard real time system where tracing of all chip internal activities over a long period of time is desired, a high speed interface requiring a larger chip area and/or alternate packaging, board design and/or tooling is cost prohibitive.
Additionally, conventional chips have trace interfaces with limited bandwidth, which allow traces for the program flow with no or only a few data accesses. However, for multi-core devices running at high frequencies, even this approach is no longer feasible economically.
Another option is to have a small on-chip trace buffer and a powerful trigger logic where the trace unit is configured to use the on-chip buffer as a circular buffer and the trace recording is stopped when it reaches the trigger. A typical error case is that a program writes a data value to a forbidden or unallowed location due to a wrong address pointer. In this case, the trigger for stopping the trace would be located on the forbidden address. This approach is helpful in situations where the root cause for the effect occurs shortly before the effect, and it is possible to trigger on the effect which is then captured in the trace. However, this approach is not ideal for all cases, especially when a longer context of the error is needed, for example, in which task and why the particular function on level N was called. For such information, a longer history is needed.
Additionally, there are trace architectures with more than one parallel Trace Unit, MSG packer, FIFO and Pins path on-chip. However, these paths are dedicated to a specific CPU, bus or subsystem and cannot be used to observe the same CPU, bus or subsystem with different trace unit settings adapted for a different output target on-chip trace buffer and off-chip trace interface.
Thus, the current architecture of conventional trace units is inadequate to support observation of long history traces, and conventional trace systems cannot be easily extended due to the overhead wiring and restricted trace memory bandwidth.
Therefore, there exists a need for a system and a method for a multi tier trace architecture for tracing a longer history context which does not significantly increase cost, efficiency or observation units required. More specifically, there is a need for a multi tier trace architecture which separates the trace data output for lower bandwidth trace information and high bandwidth trace information.